Форум dkLab и Denwer
Здесь общаются Web-разработчики.
Генеральный спонсор:
Хостинг «Джино»

Новая идеология построения Иерархической БД (Maximark)
Author Message
Maximark
Участник форума



Joined: 04 Apr 2006
Posts: 43
Карма: 1
   поощрить/наказать


PostPosted: Fri Jan 26, 2007 3:20 pm (написано за 41 минуту 30 секунд)
   Post subject: Новая идеология построения Иерархической БД
Reply with quote

На форуме очень часто разбирались методы построения иерархичесокй БД (дальше ИБД), но идеология стереотипов не позволяла всё же довести до конца (точнее будет отполировать) такую БД учитывая что что MySQl "заточен" под реляционные "связи".
Ok, скажем мускулу, почему бы не изменить идеологию проектирования.

Вся суть ИБД сводится к тому что конкретный элемент не может иметь нескольких предков... т.е. например мобильные телефон не может иметь нескольких предков т.е. "раскладушка" и "фирма"... но обратимся к матушке природе...

Мобильный телефон - это физическая величина, и она одна, а понятия "раскладушка"и "фирма" это свойства его... а предок телефона один -> его производитель. Вот мы плавно подошли к ИБД.

Преимущества ИБД очивидны - от простоты до природности. А как же "свойства" скажете Вы...
И здесь я вспомнил любимые всеми програмистами указатели. Т.е. каждое свойство мы будем УКАЗЫВАТЬ на конкретную физическу величину.

Теперь от преамбулы к архитектуре...

Содаем две таблицы.

1-я - собственно иерархическое дерево.
2-я - указатели (свойства) конкретного элемента в дереве

1-я tree
                        ----------- уровни ---------
id | page | sort | subs | id1 | id2 ............idN

2-я

id | pointer (указатель на id tree) | channel (разделение признаков) | title | .... и другие признаки


Почему мы храним всё дерево (id1 | id2 ............idN), точнее путь - для быстроты выборки (основной недостаток известных алгоритмов это тормоз like при select) обычно уровень вложенности сайта не более 10 уровней...MySQl с этим спокойно справиться.
Sort - это порядок на конкретном уровне для сортировки
Subs - это количество "детей" тоже для быстроты выборок, например "Количество комментариев" т.е. если путь /ru/products/tel/sony/k300 то комментарии в ../comments/1 2 3 и т.п.

В чем же всеже простота использования ИБД - она очевидна при построении сайта страница уникальна и выводится будет только она а все остальные параметры будут строиться для этой уникальной страницы, такие как меню, т.п.

теперь наша страница может иметь несколько "options"

т.е. страница /ru/products может иметь при channel "leftmenu" поинтер на id_tree а "topmenu" иметь поинтер на ту же страницу. В итоге при вызове из любого меню "leftmenu" или "topmenu" мы будем туже страницу (тот же физический "телефон" :))

Теперь вкусное: как будет выглядеть запрос при вызове "?path=/ru/products" :

SELECT

 (
if(T.id2=T.id, T.id1,
if(T.id3=T.id, T.id2,
''))) as pid,
  B.*,
    concat(
ifnull(concat('', T1.page ), ''),
ifnull(concat('/', T2.page ), ''),
ifnull(concat('/', T3.page ), '')
) as path

FROM
 a_tree T,
 a_base B
left join a_tree T1 on T.id1 = T1.id
left join a_tree T2 on T.id2 = T2.id
left join a_tree T3 on T.id3 = T3.id

WHERE
 T.id = B.pointer

and (B.channel='leftmenu' ) // если выводим например левое меню
and (B.publication='y')
and (T1.page ='' )
and (T2.page ='ru' )
and (T3.page ='products' )

and (T.id4=0)

order by T1.sort , T2.sort , T3.sort


Здесь всплывает еще одна новая идеология... я её назвал jumping

Вы наверное обратили внимание на and (T.id4=0) здесь мы можем "обрезать" полученные данные т.е. то что мы хотим видеть до определнного уровня. Например не хотим видеть comments
Мало того jumping удобен тем что можно "видеть" результаты от и до

т.е. например с 4 по 5 уровень (только comments)

and (T.id4=T4.id)
and (T.id5=0)

Вот и вся идеология в принципе... Реально я тестировал на 50000 записей WAPT 4.0 200 юзеров

При такой архитектуре все datalife, wp, nuke и т.п. отдыхают ...нагрузка НЕ равномерная (график), сильно подвешивают машину (кстати далеко не саму медленную Core2Duo 6600 4Gb)

При новой архитектуре нагрузка равномерная...даже не подвешивается машина.
У меня среднее выполнение CMS
 
Всего 14 запросов : 0.04227 сек.

Где 4 меню - лента новостей, голосование, популярность страниц, вывод пути, обновление, модули рейтинга и комментариев и т.п.
Мало того получается очень хорошо заточенный cms под технологию AJAX и очень проста технология шаблонов и многосайтовость...
И самое главное получилась УНИФИЦИРОВАННАЯ БД - очень гибкая....

В основе этой БД нет понятия комментарии, голосования, форумы, топики и т.п. есть одно понятие CONTENT (все комментарии, голосования, ленты новостей и т.п. строиться ОДНИМ ядром)

Единственная проблемма (недостаток) такой архитектуры как и у Nested Sets - при переносе ветки - надо пересчитывать id1, id2, id3... т.е. путь предков, но делается это тоже очень быстро :)
Хотелось бы конечно отвязаться от хранения избыточных данных (дерева пути id1, id2...) но пока не получается это обойти, может кто-нибудь отшлифует и это.

С уважением Mark
Back to top
View user's profile Send private message
Phoebus
Участник форума



Joined: 16 Nov 2003
Posts: 30
Карма: 1
   поощрить/наказать

Location: Minsk

PostPosted: Sat Jan 27, 2007 5:09 pm (спустя 1 день 1 час 48 минут; написано за 7 минут 26 секунд)
   Post subject:
Reply with quote

Мысли интересные, вот только если разложить всё что вы предложили, по полочкам, то получается следующее:
а) вы предлагаете нарушить сразу 1ую нормальную форму и хранить id-шники родителей. Идея не очень хороша, потому что во-первых, глупое ограничение на глубину, и, во-вторых, сложность при пересчете больших деревьев. В принципе, ладно, что сложность - почти такая же сложность при пересчете структуры Nested sets... Но! Nested sets, требуя такие сложности при пересчете, предлагает гораздо больше интересных возможностей! Например, получить кол-во потомков можно за один запрос (при чем забрав только одну ветвь: (lft+rgt)/2 кажется).
б) хранить всё-всё в одном дереве - это не всегда оправданно. Гораздо гибче хранить (к примеру) дерево статей в одной таблице, и деревья комментариев к статьям - в другой. У вас же, во второй таблице будет сложно совместить логику разного содержимого (как, например, в ней хранить комментарии с тремя полями и статьи -- с четырьмя). Из статьи не очень ясно.
Back to top
View user's profile Send private message Send e-mail
Maximark
Участник форума



Joined: 04 Apr 2006
Posts: 43
Карма: 1
   поощрить/наказать


PostPosted: Mon Jan 29, 2007 11:18 am (спустя 1 день 18 часов 9 минут; написано за 20 минут 2 секунды)
   Post subject:
Reply with quote

Phoebus wrote:
а) вы предлагаете нарушить сразу 1ую нормальную форму и хранить id-шники родителей.
и 3-ю тоже :)
а хранить id-шники тоже что в NS хранить кто слева и кто справа... тоже самое...у меня получился аналог материализованного пути (измененый для быстроты на больших обьемах). У меня другая идеологоия - ООП... забудем про идеологию MySQL (ну не совсем конечно) Всё равно она осталась... и все равно почти таже 3-я форма, если разобраться.
Phoebus wrote:
Идея не очень хороша, потому что во-первых, глупое ограничение на глубину
Сами как-то все говорили...сколько на сайте может быть глубина(ну никогда при такой идеологии она даже более 15 не будет а добавить уровень банальным ALTER не кто не мешает)?... Да есть недостаток... чем больше JOIN- ов все понимают тем хуже. Но не куда не деться от этого. Зато появляются куча других "вкусностей"...и в принципе нагрузка на сервер равномерная и скорость в пределах нормы. Всё работает на индексах.
Phoebus wrote:
, и, во-вторых, сложность при пересчете больших деревьев. В принципе, ладно, что сложность - почти такая же сложность при пересчете структуры Nested sets... Но! Nested sets, требуя такие сложности при пересчете, предлагает гораздо больше интересных возможностей! Например, получить кол-во потомков можно за один запрос (при чем забрав только одну ветвь: (lft+rgt)/2 кажется).
Я тоже получаю количество потомков за один запрос :) , мало того я могу гибко "отрезать" видимую часть на любом уровне...
Phoebus wrote:
б) хранить всё-всё в одном дереве - это не всегда оправданно. Гораздо гибче хранить (к примеру) дерево статей в одной таблице, и деревья комментариев к статьям - в другой.
Вас не замучали стереотипы...тендеция развития сейчас унификация... у меня разницы нет...комменты это или статьи...поймите - разная идеология...есть понятие ССЫЛКИ и КОНТЕНТ... всё! больше ничего нет... и всё уже прекрасно и быстро работает. Что статьи что комменты что голосования...всё это физическая величина КОНТЕНТ.
Phoebus wrote:
У вас же, во второй таблице будет сложно совместить логику разного содержимого (как, например, в ней хранить комментарии с тремя полями и статьи -- с четырьмя). Из статьи не очень ясно.
В том то и дело... что я ЛОГИКУ (для простоты использования обычными дизайнерами и домохозяйками) привел к одному знаменателю - ведь всё это контент.... мало того получается что всё крутит одно ядро.
Back to top
View user's profile Send private message
Phoebus
Участник форума



Joined: 16 Nov 2003
Posts: 30
Карма: 1
   поощрить/наказать

Location: Minsk

PostPosted: Mon Jan 29, 2007 5:52 pm (спустя 6 часов 33 минуты; написано за 1 минуту 7 секунд)
   Post subject:
Reply with quote

Maximark wrote:
и 3-ю тоже :)
Само собой, т.к. третяя - это и первая, и вторая.
Maximark wrote:
Phoebus писал(а):
б) хранить всё-всё в одном дереве - это не всегда оправданно. Гораздо гибче хранить (к примеру) дерево статей в одной таблице, и деревья комментариев к статьям - в другой.
Вас не замучали стереотипы...тендеция развития сейчас унификация... у меня разницы нет...комменты это или статьи...поймите - разная идеология...есть понятие ССЫЛКИ и КОНТЕНТ... всё! больше ничего нет... и всё уже прекрасно и быстро работает. Что статьи что комменты что голосования...всё это физическая величина КОНТЕНТ.
Phoebus писал(а):
У вас же, во второй таблице будет сложно совместить логику разного содержимого (как, например, в ней хранить комментарии с тремя полями и статьи -- с четырьмя). Из статьи не очень ясно.
В том то и дело... что я ЛОГИКУ (для простоты использования обычными дизайнерами и домохозяйками) привел к одному знаменателю - ведь всё это контент.... мало того получается что всё крутит одно ядро.
Вот я и говорю. Нужно хранить статьи (пять полей) и комментарии (три поля). Как вы их будете хранить, чтобы соответствие ID-шников (из таблицы с деревом и из таблицы с контентом) были корректны?
Back to top
View user's profile Send private message Send e-mail
Maximark
Участник форума



Joined: 04 Apr 2006
Posts: 43
Карма: 1
   поощрить/наказать


PostPosted: Mon Jan 29, 2007 6:47 pm (спустя 54 минуты; написано за 8 минут 6 секунд)
   Post subject:
Reply with quote

Phoebus wrote:
 Вот я и говорю. Нужно хранить статьи (пять полей) и комментарии (три поля). Как вы их будете хранить, чтобы соответствие ID-шников (из таблицы с деревом и из таблицы с контентом) были корректны?
[/quote]

Давайте поймем логику всего контента.
1. id
2. в нашем случае указатель на физическую "величину"
3. Заголовок
4. Краткое описание
5. Дата
6. Дата публикации
7. Дата конца публикации
8. Counter
9. Rating

Под это всё попадает любой конетент и комментарии и статьи ... и даже файлы.

добавим еще
10. Option (где будем хранить serialize второстепенные данные)...да можно и полями (без разницы)

Я долго анализировал чем же отличаются комменты например от постов форума или статей... да ничем вообще, даже голосование. Всё отличие в шаблонах вывода.
Могу дать ссылку работающего ядра CMS, я думаю наглядное пособие лучше. Но только в приват, там еще нет проверки на безопастность (пока нет, всего одну функцию дописать)
Back to top
View user's profile Send private message
Maximark
Участник форума



Joined: 04 Apr 2006
Posts: 43
Карма: 1
   поощрить/наказать


PostPosted: Fri Mar 30, 2007 9:54 am (спустя 2 месяца 15 часов 6 минут; написано за 2 минуты 48 секунд)
   Post subject:
Reply with quote

Кто хочет протестить уже практическую реализацию новой идеологии, писать в приват - дам адрес.
Иеология действительно необычна... всё крутится одним ядром и унифицированна, также отличает отделение кода ядра от шаблонов, минимальным количеством запросов, заточена под dkajax, там же реализован доступ аля unix к веткам.
Уже всё работает и крутится
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic All times are GMT + 3 Hours
Page 1 of 1    Email to a Friend.
You cannot post new topics in this forum. You cannot reply to topics in this forum. You cannot edit your posts in this forum. You cannot delete your posts in this forum. You cannot vote in polls in this forum. You cannot attach files in this forum. You can download files in this forum.
XML